@typescript-bot pack this
@typescript-bot perf test this faster

Heya @DanielRosenwasser, I've started to run the abridged perf test suite on this PR at 59b288f. You can monitor the build here.

Update: The results are in!

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 59b288f. You can monitor the build here.

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/139777/artifacts?artifactName=tgz&fileId=B223ACDEB83D122D053BD5B40F019EFCDFB6B130B6F8D1C7352743A53849F7C102&fileName=/typescript-5.0.0-insiders.20221206.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.0.0-pr-51753-3".;

@DanielRosenwasser
The results of the perf run you requested are in!

@typescript-bot pack this

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 7d823ae. You can monitor the build here.

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/140624/artifacts?artifactName=tgz&fileId=8FDCD5FB7CADB661C4A0D07B8E2D6E6DE6E5355F6DA223FD860F7C1DA8FD722702&fileName=/typescript-5.0.0-insiders.20221216.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.0.0-pr-51753-8".;

@DanielRosenwasser Could you take a look at these changes? I want to be sure about

We would like @satisfies to also work in declaration positions - enforce the assignability check on, and also contextually type, the initializer expression(s?).

I think the specific use case we had in mind was a @satisfies tag before the declaration itself.

/** @satisfies {{ f: (x: string) => string }} */
let obj1 = { f: s => s.toLowerCase() }; // should work

/** @satisfies {{ f: (x: string) => string }} */
let obj2 = { g: "oops" }; // should error

similar to how an @type tag can be placed.

@DanielRosenwasser
The results of the perf run you requested are in!

@typescript-bot pack this

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 98f7db6. You can monitor the build here.

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/142614/artifacts?artifactName=tgz&fileId=756144B95058A4FAC8E38B6C37F3A8CBF6D0B1004881585CC04226C896A1A04602&fileName=/typescript-5.0.0-insiders.20230113.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.0.0-pr-51753-19".;

So we tried @satisfies a little bit today and here's what we noticed.

• @satisfies is not currently offered in completions for JSDoc tag names for declaration positions.

  /** @$ */
  let x = 10;

• There are no type name completions in the braces of /** @satisfies {$} */

Those are the two things I would want to get fixed with this PR.

Something minor that we noticed was that there are mismatches between what TypeScript does in annotation/assertion/satisfies positions, along with what the corresponding JSDoc equivalents are.

// TS file
let a: string = 123;
//  ~

let b = 123 as string;
//      ~~~~~~~~~~~~~

let c = 123 satisfies string;
//                    ~~~~~~

// JS file
/** @satisfies {string} */
let a = 123;
//  ~

let b = /** @type {string} */ (123);
//                 ~~~~~~

/** @satisfies {string} */
//              ~~~~~~
let c = 123;

let d = /** @satisfies {string} */ (123);
//                      ~~~~~~

These are not consistent, but to be honest, I don't want you to change what you have in this PR because it would end up dragging it on and it's a separate concern from the feature itself. I'd rather file a separate follow-up issue instead.